Printing devices are devices that can print viewable content on physical media, such as paper or transparent sheets. Printing devices include printers and multi-function peripherals (MFPs) such as the Ricoh Aficio 5560 system. Typically, a printing device receives data from a computer via a network or cable. The printing device prints text/or and images that are represented by the data.
Different printing devices may offer different features. Different printing devices may have different characteristics and capabilities. It is often useful for a client, such as an application program (e.g., a word processor) or print driver, to be able to obtain information about a printing device with which that client intends to interact. For example, if a printing device can print in either black and white or in color, then it may be useful for a client to know that the printing device has such a capability. Knowing that a printing device has the ability to print in color might influence the kind of commands that the client sends to the printing device.
In order to enable clients to learn the features, characteristics, and capabilities of a printing device, some printing devices store (e.g., in volatile or non-volatile memory) metadata that indicates features, characteristics, and capabilities of those printing devices. A client can send, to such a printing device, a request for that printing device's metadata. The printing device can receive such a request and respond to the request by sending, to the client, the printing device's metadata (or a specifically requested portion thereof). The client can receive the metadata and use the metadata to customize the manner in which the client interacts with the printing device. Thus, a client can automatically learn about a printing device's features, characteristics, and capabilities.
A device's metadata might indicate information such as the device's manufacturer, the device's model, the device's Internet Protocol (IP) address, etc. Under some circumstances, a client might be unable to interact in a desired manner with a printing device until the client has obtained at least some of the printing device's metadata.
Typically, a client requests metadata from a printing device in a manner that conforms to a specified “retrieving protocol.” The retrieving protocol may indicate, for example, the form and/or order of messages that a client ought to send to a printing device in order to request or retrieve that printing device's metadata. If a client and a printing device do not follow a mutually understood retrieving protocol, then the printing device might not be able to recognize what the client wants from the printing device.
Additionally, a printing device typically sends metadata to a client in a manner that conforms to a specified “packaging protocol.” The packaging protocol may indicate, for example, the form and/or structure that the metadata ought to take when sent to the client. For example, a packaging protocol might indicate that metadata should be sent as plain text, or in a comma-delimited format, or as an Extensible Markup Language (“XML”) document that conforms to a specified schema. If a client and a printing device do not follow a mutually understood packaging protocol, then the client might not be able to recognize what is meant by the metadata that the printing device sends to the client.
Some retrieving protocols and packaging protocols are specifically designed to enable a client to obtain a device's metadata over a network, or even over a series of interconnected networks such as the Internet. Using such protocols, a client can automatically discover the features, characteristics, and capabilities of devices even if those devices are miles away, so long as both the client and those devices are connected to the Internet.
Different clients may conform to different standards. The retrieving and packaging protocols that a client uses to obtain and interpret metadata may vary depending upon the standard to which the client conforms. Clients that conform to the Universal Plug and Play (“UPNP”) standard typically use Hypertext Transfer Protocol (“HTTP”) Get as a retrieving protocol and a device template protocol as a packaging protocol. In contrast, clients that conform to the Web Service Device (“WSD”) standard now typically use the WS-Transfer protocol (specified by the World Wide Web Consortium) as a retrieving protocol and the WS-Device Profile protocol (also specified by the World Wide Web Consortium) as a packaging protocol.
In order to be able to communicate metadata to a variety of different types of clients, a printing device might comprise a different module for each different possible standard to which a client might conform. For example, a printing device might comprise both (a) a UPNP module that receives and responds to metadata requests from clients that conform to the UPNP standard (“UPNP clients”) and (b) a WSD module that receives and responds to metadata requests from clients that conform to the WSD standard (“WSD clients”). The UPNP module might use HTTP GET and a device template protocol, while the WSD module might use the WS-Transfer and WS-Device Profile protocols, for example. Each module might be implemented as a different sequence of machine-executable instructions.
Although the above approach would have its uses, the above approach also would suffer somewhat due to inflexibility. Initially, clients that conform to a particular standard might all use a particular retrieving protocol and a particular packaging protocol (as dictated by the particular standard). However, over time, as newer and better protocols become available, existing protocols tend to evolve to dictate the use of the newer protocols instead of the older protocols. Thus, later, those same clients that conform to the particular protocol might evolve to use a newer, better, retrieving protocol (but such clients might continue to use the original packaging protocol). Under such circumstances, a printing device's module that implemented the original retrieving and packaging protocols in a tightly coupled manner would no longer be usable to communicate metadata to clients that conformed to the particular standard. Under such circumstances, a new module that implemented both the original packaging protocol and the new retrieving protocol might need to be created and installed on the printing device in order to enable the printing device to receive and respond to metadata requests from such clients.
Additionally, if there were no other standard that still used both the original retrieving and packaging protocols together, then the module that implemented both the original retrieving and packaging protocols would become obsolete and useless. Sadly, this would be the case even if some other standard still used the original retrieving protocol (but not the original packaging protocol) and even if some other standard still used the original packaging protocol (but not the original retrieving protocol).
Similar troubles might arise in the event that an entirely new standard was published and widely adopted by clients. Such a new standard might even use existing retrieving and packaging protocols, but such a new standard might use a different combination of existing retrieving and packaging protocols than any combination used by any other previous standard. It might be that no module for any existing standard implemented the particular combination of existing retrieving and packaging protocols together. Under such circumstances, an entirely new module for the new standard might need to be created and installed on the printing device even though the existing retrieving and packaging protocols has previously been implemented within existing modules (just never together in the same module).
Thus, if used, the above approach might, over time, necessitate the expenditure of a large amount of time and effort by those who create modules for the printing device. Additionally, if used, the above approach might, over time, produce large quantities of obsolete, un-reusable code.
Furthermore, given a sufficiently large number of different retrieving protocols and a sufficiently large number of different packaging protocols (all of which might concurrently be used by different standards, but in different combinations), the number of different possible combinations of retrieving and packaging protocols could become overwhelmingly enormous. If a printing device was required to maintain a separate module for each different combination, and if each module fully implemented both a retrieving protocol and a packaging protocol, then the amount of memory and/or persistent storage space that the printing device would need in order to maintain those modules might be significant.
The above approach, if used, could be very wasteful of printing device resources and human programming effort. Based on the foregoing, there is a need for a less wasteful approach for communicating metadata between devices and the diverse kinds of clients that interact with those devices.